[Amazon FSx for NetApp ONTAP] スループットキャパシティがボリュームバックアップ速度に影響を与えるのか確認してみた

[Amazon FSx for NetApp ONTAP] スループットキャパシティがボリュームバックアップ速度に影響を与えるのか確認してみた

スループットキャパシティはバックアップ速度に大きな影響がある
Clock Icon2025.01.19

リストア速度は圧倒的な差は感じなかったが、バックアップ速度はどうだろう

こんにちは、のんピ(@non____97)です。

皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)ファイルシステムに設定したスループットキャパシティがバックアップ速度に影響があるのか気になったことはありますか? 私はあります。

以下記事でリストア速度に圧倒的な差はないことを確認しました。

https://dev.classmethod.jp/articles/amazon-fsx-for-netapp-ontap-throughput-capacity-impact-on-restore-speed/

では、バックアップ速度はどうでしょうか。

上述の記事では800GiBのデータを含むボリュームの初回バックアップにかかった時間が26分であることを紹介しました。速度で表現すると525MBpsです。

実際に他のスループットキャパシティでもバックアップをしてみて、どのぐらい速度に影響がるのか確認してみました。

いきなりまとめ

  • 検証した限り、スループットキャパシティを増強すると、バックアップ対象のデータ転送速度がその分改善される

    スループットキャパシティ バックアップ実行時間 バックアップ実行開始から完了までの速度 データ転送速度
    128MBps 1時間26分 159MiBps 200MiBps
    256MBps 46分 297MiBps 400MiBps
    512MBps 27分 506MiBps 800MiBps
  • 初回バックアップ時や大きくデータ更新があった場合にはスループットキャパシティを増強しておくのも手

やってみた

スループットキャパシティ128MBpsの場合

まず、スループットキャパシティが128MBpsの場合です。

5.128MBps.png

バックアップ対象のボリュームは上述の記事で用意した800GiBのデータを含むボリュームです。

また、FSxNのボリュームバックアップは差分バックアップです。

すべての Amazon FSxバックアップ (自動日次バックアップとユーザー主導バックアップ) は増分的です。つまり、前回のバックアップが完了した以降のデータにのみ変更が保存されます。これにより、バックアップの作成に必要な時間と、各バックアップで使用されるストレージの量の両方が最小限に抑えられます。増分バックアップは、重複データを保存しないことでストレージコストを最適化します。 ONTAP バックアップFSxの はボリュームごとであり、各バックアップには 1 つの特定のボリュームのデータのみが含まれます。Amazon FSxバックアップは、高い耐久性を実現するために、複数のアベイラビリティーゾーンに冗長的に保存されます。

Amazon FSxバックアップは point-in-time、ボリュームの読み取り専用イメージであるスナップショットを使用して、バックアップ間の増分を維持します。バックアップが作成されるたびに、Amazon はFSxまずボリュームのスナップショットを作成します。バックアップスナップショットはボリュームに格納され、ボリュームのストレージ領域を消費します。FSx 次に、Amazon はこのスナップショットを以前のバックアップスナップショット (存在する場合) と比較し、変更されたデータのみをバックアップにコピーします。

以前のバックアップスナップショットが存在しない場合は、最新のバックアップスナップショットの内容全体がバックアップにコピーされます。最新のバックアップスナップショットが正常に作成されると、Amazon は以前のバックアップスナップショットFSxを削除します。プロセスが繰り返される場合、最新のバックアップに使用されたスナップショットは、次のバックアップが作成されるまで、ボリュームに残ります。バックアップストレージコストを最適化するには、ONTAP は、ボリュームのストレージ効率の節約をバックアップに保持します。

バックアップを削除すると、そのバックアップに固有のデータのみが削除されます。各 Amazon FSxバックアップには、バックアップから新しいボリュームを作成し、ボリュームのスナップショットを効果的に復元 point-in-timeするために必要なすべての情報が含まれています。

バックアップジョブを実行する前にバックアップ対象のボリュームの全てのボリュームバックアップを削除しておきます。

ボリュームバックアップによるデータの保護 - ONTAP 用の FSx

全てのボリュームバックアップの削除が完了したら、AWS Backupからオンデマンドバックアップジョブを実行します。

1.128Mbpsでバックアップジョブを作成.png

バックアップは1時間26分で完了しました。バックアップ速度は単純計算で、159MiBpsです。

3.1時間26分で完了.png

バックアップはAWS Backupのコンソールからだけでなく、FSxのコンソールからでも確認できます。

2.バックアップ取得完了.png

バックアップ実行時のFSxNファイルシステムのByte関連のメトリクスを確認します。

4.128MBpsでバックアップ中のByteメトリクス_2.png

NetworkSentBytesNetworkReceivedBytesCapacityPoolReadBytesが跳ねていることが分かります。つまり、キャパシティプールストレージの読み込んで転送しているということですね。

FSxNファイルシステムのパフォーマンスのメトリクスは以下のとおりです。

7.128MBpsの場合のファイルサーバーのパフォーマンス.png

ネットワークスループットとCPU使用率がバックアップ実行中は張り付いています。ネットワークスループットに至っては100%を超えていることからバーストしています。

スループットキャパシティ256MBpsの場合

続いて、スループットキャパシティ256MBpsの場合です。

8.256MBps.png

先ほど取得したボリュームバックアップの削除が完了したら、同様にAWS Backupからオンデマンドバックアップジョブを実行します。

バックアップは46分で完了しました。先ほどの約半分ですね。バックアップ速度は単純計算で、297MiBpsです。

9.46分で完了.png

バックアップ実行時のFSxNファイルシステムのByte関連のメトリクスを確認します。

11.256MBpsでバックアップ中のByteメトリクス_2.png

跳ねているメトリクスは同じですが、跳ねている量が異なります。128MBpsの場合は12GiBpmから13GiBpm程度でしたが、256MBの場合は22GiBpmから26GiBpmです。ここからもバックアップ速度が倍速になっていることを確認できますね。

FSxNファイルシステムのパフォーマンスのメトリクスは以下のとおりです。

10.256MBpsの場合のファイルサーバーのパフォーマンス.png

跳ねているメトリクスは同じですが、跳ねている時間が短いですね。

スループットキャパシティ512MBpsの場合

最後に、スループットキャパシティ512MBpsの場合です。

12.512MBps.png

先ほど取得したボリュームバックアップの削除が完了したら、同様にAWS Backupからオンデマンドバックアップジョブを実行します。

バックアップは27分で完了しました。256MBpsの場合のさらに約半分ですね。バックアップ速度は単純計算で、506MiBpsです。

13.27分で完了.png

先述の記事で512MBpsの場合は26分で完了したので、ほとんど誤差ですね。

バックアップ実行時のFSxNファイルシステムのByte関連のメトリクスを確認します。

14.512MBpsでバックアップ中のByteメトリクス_2.png

今回も跳ねているメトリクスは同じですが、跳ねている量が異なります。128MBpsの場合は12GiBpmから13GiBpm程度、256MBの場合は22GiBpmから26GiBpmでしたが、512MBの場合は41GiBpmから50GiBpmです。綺麗にバックアップ速度が倍速になっていることを確認できます。

FSxNファイルシステムのパフォーマンスのメトリクスは以下のとおりです。

10.512MBpsの場合のファイルサーバーのパフォーマンス.png

さらにネットワークスループットとCPU使用率が張り付く時間が短くなりました。

スループットキャパシティごとのByteメトリクスとパフォーマンスメトリクスの比較

せっかくなので、スループットキャパシティごとのByteメトリクスとパフォーマンスメトリクスの比較をします。

まずはByte関連のメトリクスです。

16.スループットキャパシティごとのバックアップ時のByteメトリクス.png

綺麗にスループットキャパシティを倍々にすると、転送量も倍々になっていることが分かります。

転送速度をMiBpsと分かりやすくするために[max: ${MAX}, last: ${LAST}] GiBMETRICS()/1073741824になっている箇所を[max: ${MAX}, last: ${LAST}] MiBpsMETRICS()/1048576/PERIOD(m1)に変更します。

17.スループットキャパシティごとのバックアップ時のByteメトリクス(MiBps).png

スループットキャパシティ 転送速度
128MBps 200MiBps
256MBps 400MiBps
512MBps 800MiBps

というように綺麗に転送速度が増加していることが分かりますね。

最後にファイルサーバーのパフォーマンスのメトリクスを確認します。

18.スループットキャパシティごとのバックアップ時のファイルサーバーのパフォーマンス.png

スループットキャパシティを増強する度に、ネットワークスループットとCPU使用率が張り付く時間が半分になっていることが確認できました。

スループットキャパシティはバックアップ速度に大きな影響がある

Amazon FSx for NetApp ONTAPのスループットキャパシティがボリュームバックアップ速度に影響を与えるのか確認してみました。

結論としてはスループットキャパシティはバックアップ速度に大きな影響を与えます。

初回のバックアップや移行などで大量のデータ更新があった際でも、バックアップ取得時間を短くしたい場合はスループットキャパシティを増強すると良さそうです。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.